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(54) System for secure transactions 

(57) A multimedia network (1) with connected cus- 
tomer stations (2), merchant servers (3), and a payment 
server (5). Secure electronic transactions are per- 
formed using a secure electronic transactions protocol 
(SET), inciudlng exchange of digital certificates, man- 
aged by a Trusted Third Party Server (9). The customer 
stations comprise transactions management means 
(10). fit for performing said SET protocoi and for manag- 
ing said certificates for the customer station, A remote 
customer agent (13) represents the customer station in 
the negotiation and payment process. The customer 
station (2) comprises an agent interface (12), fit for 
transmission of codes, parameters and certificates 
between the customer agent (13) and the transactions 
management means (10). A remote merchant agent 
(14) represents the merchant station (3) in the negotia- 
tion and payment process with the customer agent (13) 
or the customer station (3), to have paid for the selected 
products in a secure way, urder controi of SET protocoi- 
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Description 

BACKGROUND OF THE iNVENTION 

[0001 ] The invention relates to a system for the exe- 5 
cutaon of secure transactsons in a muStimedaa network 
[0002] Multam^la networks like the internet offer a 
wide variety of new possibilities, which wiii have a great 
ar^ipact on the business environment of the future. Vari- 
ous vendors will start to exploit the internet as a market- io 
place. For a customer not to get lost within the vast 
arr?ount of information that is provided, in the near futiire 
agent-based services shaH be ir^ipiemented. Agents are 
autonomous pieces of software, which may perform 
tasks for users on the internet. Based on the user's pref- 15 
erences, they may assist the user in making a selection 
within the vast range of o^ered pcxiucts. Gompiemen- 
tary to this, the agent may assist in the actual purchase 
of such a product. As part of this process, the agent wil^ 
have to be able to perform payments. 20 
[0003] One of the biggest inhibitors on Electronic 
Commerce today is securaty Consumers demand that 
their private information be kept private. When using 
agent technology within an E-Comm@rce service, ade- 
quate security precautions must be taken. At present, 25 
however, agent security is stiil in its infancy Therefore, 
delegating payments to agents is not possible at this 
moment in time. 

SUMMARY OF THE INVENTION 30 

[0004] According to the present invention, an archi- 
tecture fs proposed in which agents may perform secure 
credit card payments. According to the invention, for the 
execution of such payments the SET (Secure Electronic 35 
Transactions) protocol is used, an upcoming standard 
for secure payments on the Internet by means of credit 
cards. All new entities and components that are neces- 
sary to provide agent-based SET payments will be 
defined and payment interaction (agent-agent, agent- 40 
user and other) wall be elaborated upon 
[0005] Most entities of the standard infrastructure 
for performing SET-foased payments by means of credit 
cards are straightforward analogies to reai world credit 
card payments. A few, however, need further e)cplana- 45 
Won. A brief description of these ml\ be given first 
[0006] One of the main issues when providing 
secure payments is authentication of the involved enti- 
ties. SET uses a robust set of digital certificates for this 
purpose. Each participant in a SET transaction requires so 
a specific certificate or set of certificates that not only 
uniquely identifies this participant, but also attests to his 
or hsr privilege as holder of a payment card or as a 
holder of a Merchant account. Brand Associations (e.g. 
VIS.A/MasterGard) or Card issuers commission so 55 
caSied Certificate Authorities (CAs) to carry out the work 
of managing SET digital certificates, 
[0007] Complementary to this, SET introduces the 



notion of a Payment Gateway, which is ne^ed to vali- 
date SET digital certificates and preprocess authorisa- 
tion, capture and settlement work concerning the 
payment at hand. Another fundamental requirement for 
performing SET payments is a component called an 
Electronic Wallet (E~Wallet). These wallets embody the 
SET protocol on the customer side and provide a 
means to store and manage the certificates to digitally 
sign messages, along with the security aspects con- 
sumers demand to keep private data private. 
[0008] According to the present invention the task 
of performing SET credit card transactions is delegated 
to agents. In developing an infrastructure that enables 
this, the following constraints have been defined: 

Obtaining certificates is not a task that users will 
want to delegate to their agents. Furthermore, it is 
not very probable that banks and CAs win approve 
of this situation. Therefore, we assume all certifi- 
cates and the E-Waliet to be in place. 
The standard SET infrastructure shall be kept 
Intact. Thereby the inherent security of SET pay- 
ments shall remain present and the necessary 
alterations when implementing shall be limited. 

[0009] Based on these constraints, an infrastruc- 
ture has been designed wich will be discussed beiow. 

EMBODIMENT OF THE INVENTION 

[0010] Figure 1 shows an architecture in which the 
invention -the use the SET protocol by ''secure agents- 
can be implemented. Figure 1 shows a multimedia net- 
work -the internet- 1 . 

[0011] Connected to the internet 1 are customer 
PCs 2, and merchant servers 3, each via an internet 
service providers (ISP) 4. Aiso connected to the inter- 
net, via an ISP 4, is a payment (gateway) server 5. The 
payment server 5 is also - via an access server 6- con- 
nected to a "Banker's Interchange Network" (BIN) 7, 
having banking servers 8 connected to it. 
[0012] A main issue in secure payments is authen- 
tication of entities. The SET protocol, to be used in the 
system shown In figure 1 , uses a set of digital certifi- 
cates for this purpose. Each participant in transaction 
require a certificate that uniquely identities the partici- 
pant and also attests to his privilege as a holder of a 
account at the merchant server. Associations like 
VISA/'MasterCard or other Card Issuers commission so 
called Certificate Authorities to carry out the work of 
managing SET digital certificates. In figure 1 a Trusted 
Third Party Server (TTPS) 9 of such Certificate Author- 
ity is connected to the internet 1 and can be approached 
by customers 2, merchants 3 and payment servers 5, 
Payment servers 5 are needed to validate the digital 
certificates and to preprocess authorisation, capture 
and settlement work concerning the payment. 
[0013] Another fundamental requirement for per- 
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formmg SET payments is a system component caiied 
"Eiectronic Waiief (EW) 10. An E-waHet 10 embodies 
the SET protocol at the customer's side and provides 
means -within the customer's PC 2-- to store and man- 
age the needed certificates, to digitaiiy sign messages, 5 
aiong with the security aspects customers demand to 
keep private data private, 

[001 4J According to the invention agents are used 
to perforr^i secure transactions. As said before, agents 
are autonomous pieces of software, which are enabled 10 
to perform tasks for users (customers or merchants). 
Based on preferences set by users 2 (customer) and 3 
(merchant), the users* respective agents assists or rep- 
resent the users in presenting and selecting of the mer- 
chants' products and, compiementary to this, the users' 15 
re^ective agents assast or represents the users to pur- 
chase {collect) the selected products and to perform the 
secure payment for it. 

[00151 Each customer 2 may be represented by a 
customer agent (CA), while each merchant 3 may be 20 
represented by a merchant agent (MA). The negotiation 
process (presentation, selection and coilectlon of prod- 
ucts and the payments for the collected products) is 
executed within an "agent platform", preferably embod- 
i^ within an "Agent Negotiation Server" (ANS) 11. 25 
Communication between the customer's PC 3 and the 
customer's agent at the ANS's side is peslormed, at the 
customer's side via the E-wallet 10 -meant for SET 
based transaction- which is extended with a special 
SET Agent Interface (SAI) 12. so 
[001 6| The CA 1 3 communicates with the customer 
by means of the customer's "browser" (customer inter- 
face) and, via the SAI 12, with the customer's E~Wal!et 
10 in order to initialise payments. As was the case 
according to the state-of-the-art (using credit cards), the 35 
actual SET payment process Is peribrmsd between the 
E-Wailet 10 and the Merchant server 3. Therefore, dur- 
ing actuaB payment interaction the level of trust is the 
same as in known, credit card based SET payments. 
[0017] The CA 13 will have to be authorised to ini- 40 
tialise the EW 10 for payments, in standard SET trans- 
actions the customer is prompted -via the customer's 
browser- to enter the E~Wallet password for this pur- 
pose. The CA 13 and the SAI 12 will have to be imple- 
mented such, that one of two scenarios may be 45 
performed; either the OA 13 has authorisation to 
release the cryptographic content of the E~Waliet 10 
itself, or, after agent initiaiisatlon, the customer is 
prompted to provide an E -Wallet password-. In the latter 
case, customer interaction is necessary. This is not so 
desirable from a usability point of view, but might be pre- 
ferred by customers (or merchants), since this will give 
them a sense of control over the payment. 
[001 BS Figure 2 shows a communication procedure 
for the system presented in figure 1 . 55 
[00191 For authentication and authorisation pur- 
poses, the OA 13 wall carry a token, In which an author- 
isation cede for opening up the E-Wallet is 
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encapsulated. The ievel at which this token is secured 
wsthin the agent depends on the location of the platform 
In which the CA 13 peslornis its tasks. If this platform 
resides on the customer PC, security requirements on 
both storing the token within the agent and communicat- 
ing it to the E~Wa!let are less strong than if the agent 
resides on a remote platform like the ANS 1 1 as sug- 
gested in figure 1 . In the latter case, the token wall need 
to be adequately secured, as wlli, communication 
between the agent and the E-Wallet. The security 
requirements are as follows: 

The token is stored within the GA 13 In encrypted 
form, using a random key A symmetric encryption 
scheme, such as DES, shall be applied here. This 
random key is generated at the PC 2 for each spe- 
cific purchase. A new key shasi be generated for 
each item that is to be bought by the agent. 
For communication purposes, both the customer 2 
and the CA 13 need to own a specific certificate, 
other than the SET certificate. Payment start mes- 
sages shall be communacated to the E-Wallet 10 In 
encrypted form, using a random session key. A 
symmetric encryption scheme^ such as DES, shall 
be appsied here. In turn, this random key shall be 
sent over in encrypted form, using the customer's 
public key related to the communication certificate. 
The message shall be signed with the agents pri- 
vate key and a time stamp shall be added to the 
message in order to prevent replay by malicious 
parties. 

[0020] In figure 2 the foiiowing communication 
steps are performed: 

In step i, the CA 13 requests the Merchant Agent 
(MA) 14 to pay by credit card. The latter then 
informs the merchant server 3 of the r^uested 
payment, while parallell to that the CA 13 initialises 
the EW 10. 

in step IL the standard SET procedure is performed 
by the EW 10, the Merchant server 3 and the Pay- 
ment Gateway server 5, 

Finally in step 111, after completion of the payment, 
the Merchant server 3 informs the MA 14 of this 
tact. The MA 14 passes this message on to the CA 
13, which notifies the customer of payment comple- 
tion. 

[0021] The infrastructure and message flows are a 
natural extension of any agent-based infrastructure. 
Implementation may therefore by performed straightfor- 
wardly. 

Claims 

1 . System for the execution of secure transactions in a 
multimedia network, comprising a multimedia net- 
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work mth customer stations (2), merchant servers 
(3), and a payment server (5) connected to it, 
secure electronic transactions being peiiormed 
using a secure electronic transactions protocol, 
comprising the exchange of dagitai certificates, 5 
uniquely identifying the relevant transaction partici- 
pants and also attesting their privileges at the mer- 
chant server, said certH^icates being manage by a 
Trusted Third Party Server (9) being connected too 
to said muitimedia network, said payment servers 5 w 
being enabled to vaiidate the digital certificates pre- 
sented and to process authorisation concerning the 
payment, said customer stations comprising trans- 
actions management means (10), fit for performing 
said secure electronic transactions protocol and for 15 
managing said certificates for the customer station, 
characterized In a remote customer agent (13), 
managed by agent parameters received or to be 
received from said customer station (2) and thus, 
under the control of said parameters, assisting or 20 
representing the customer station in a negotiation 
process, including selecting products to be pre- 
sented by the merchant server (3), and payment for 
selected products in a secure way, under control of 
said secure electronic transactions protocol and 25 
said certificates, being managed by said transac- 
tions management means (10). 

2. System according to claim 1 , 

charactera^ed m that said customer station (2) 30 
comprises an agent interface 1 2, fit for transmission 
of codes, parameters and certificates between said 
customer agent (13) and said transactions man- 
agement means (10). 

35 

3. System according to claim 1 , 

characterised \n a remote merchant agent (14), 
managed by agent parameters receive or to be 
received from said merchant station (3) and thus, 
under the control of said parameters, assisting or 40 
representing the merchant station In a negotiation 
process, including presenting products to the cus- 
tomer agent (13) or the customer station (3), and to 
have paid for products being selected by the cus- 
tomer agent (13) or the customer station (3), in a 45 
secure way under control of said secure electronic 
transactions protocol and said certificates, 

4. System according to claim 2, 

characterised m that said negotiation and pay- 50 
ment process by said customer agent (13) and said 
merchant agent (14) is performed within an agent 
negotiation server (11). connected to said multime- 
dia network (1). 

55 

5. System according to claim 1 , 

characterised m that, within said secure electronic 
transaction protocoL for authentication and authori- 



sation said customer agent (1 3) transmits a token is 
encapsulated, comprising an authorisation code for 
opening up said transactions management means 
(10)^ 

6. System according to claim 5, 

charactsrased In that said token is stored within the 
customer agent (13) in an encrypted form, using a 
random key being generated at the customer sta- 
tion (2) for each new payment process. 

7. System according to claim 5, 

charactsrased an that both the customer station (2) 
and the customer agent (13) comprise a specific 
communication certificate, payment start mes- 
sages being communicated to said transactions 
management means (10) in encrypted form, using 
a random session key which, in turn, is sent over in 
encrypted form, using the customer station's pubNc 
key related to said communication certificate, said 
message being signed with the customer agent's 
private key related to said communication certifi- 
oate and a time stamp being added to said mes- 
sage in order to prevent replay by malicious parties. 

8. Method for the execution of secure transactions in a 
multimedia network, comprising a multimedia net- 
work with customer stations (2), merchant servers 
(3), and a payment server (5) connected to it. 
secure electronic transactions being performed 
using a secure electronic transactions protocol, 
comprising the exchange of digital certificates, 
uniquely Identifying the relevant transaction partici- 
pants and also attesting their privileges at the mer- 
chant server, said certificates being managed by a 
Trusted Third Party Server (9) being connected too 
to said multimedia network, said payment servers 5 
being enabled to validate the digital certificates pre- 
senta:^ and to process authorisation concerning the 
payment, said customer stations comprising trans- 
actions management means (10), fit for performing 
said secure electronic transactions protocol and for 
managing said certificates for the customer station, 
moreover comprising a remote customer agent 
(13), managed by agent parameters received or to 
be received from said customer station (2) and 
thus, under the controi of said parameters, assist- 
ing or representing the customer station in a nego- 
tiation process, including selecting products to be 
presented by the merchant server (3), and payment 
for selected products in a secure way, under control 
of said secure electronic transactions protocol and 
said certificates, being managed by said transac- 
tions management means (10), while, moreover 
said customer station (2) comprises an agent inter- 
face (12), fit for transmission of codes, parameters 
and certificates between said customer agent (13) 
and said transactions management means (10), 
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and, besides, a remote merchant agent (14), man- 
aged by agent parameters received or to be 
received from said merchant station (3} and thus, 
under the control of sa^d parameters, assisting or 
representing the merchard; station en a negotiation 5 
process, inciuding preaentang products to the cus- 
tomer agent (1 3) or the customer station (3), and to 
have paid for products being selected by the cus- 
tomer agent (13) or the customer station (3), in a 
secure way; under control of said secure electronic w 
transactions protocoi and said certlfacates, charac- 
terized In the foHowsng communfcation steps: 

In a first step, said customer agent (13) 
requests said merchant agent (14) to pay by 15 
credit card, and the merchant agent then 
informs said merchant server (3) of the 
requested payment, while paraiieli to that the 
the customer agent (1 3) inatialises said transac- 
tions management means (10); 20 
in a second step, a standard secure electronic 
transaction procedure is performed by the 
transactions management means (10), the 
merchant server (3) and the payment gateway 
server (5); 25 
an a third, final step, after compietion of the pay- 
ment process, the merchant server (3) informs 
the merchant agent (14) of that compietion of 
the payment process, and the merchant agent 
(14) passes this message on to the customer so 
agent (13), which notifies the customer station 
(2) of the payment completion. 
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